It has become a common approach to write programs for 32 bit versions of Microsoft Windows® (e.g., NT, 2000, XP, 2003) that remotely control the operations and behaviors of other running Windows processes. There are various existing applications that utilize this feature provided by the Windows NT based operating systems. For instance, a SPAM blocker program may remotely inject a dynamic link library into the address space of another Windows application, filter all the web and e-mail traffic, and block SPAM based e-mail.
Typically, the mechanism for remotely controlling an application is to inject code bytes into the address space of the target process, and then to create a remote thread that executes those code bytes. Jeffrey Richter, in his book Programming Applications for Microsoft Windows (Fourth Edition) articulates detailed implementation mechanics for this known technique.
However, the known methods for remotely controlling processes all have certain security requirements that are dictated by Windows. In particular, the program that is to remotely control the target process must have very specific and extensive access rights to the remote process space, in order to write the code bytes thereto. If the access token of the target process does not allow the calling process to obtain those access rights, then the write operation will fail. Thus, the controlling process must be run from a highly privileged user account. Normally, this is done by registering the controlling process as a service that runs in the local system account.
Additionally, for the controlling process to be able to create a remote thread inside the target process, it has to have debug privilege, in order to be able to access the process handle of the target process. By default, Windows allows only system administrators to have debug privilege. This additional security measure started with Windows 2003, in order to provide process level protection against debug attachment commands, and against creation of threads remotely by another process. Certain user accounts such as the local system account have this built in system level protection. There is no known user mode based solution by which a program without debug privilege can obtain a process handle. Furthermore, being able to access and duplicate other handles owned by the target process (e.g., a pipe handle, a time handle) without having debug privileges would be of further use to the source process in controlling the target process, or for other purposes.
What is needed are methods, systems and computer readable media for duplicating handles of remote target processes, without requiring the source process to be run from a highly privileged user account, and without requiring the source process to have debug privilege.